1. Field of the Invention
This invention relates to computer networks and, more specifically to resource sharing among RSVP sessions.
2. Background Information
Computer networks typically comprise a plurality of interconnected entities. An entity may consist of any device, such as a computer or end station, that “sources” (i.e., transmits) or “sinks” (i.e., receives) datagrams (e.g., packets and/or frames). A common type of computer network is a local area network (“LAN”) which typically refers to a privately owned network within a single building or campus. LANs typically employ a data communication protocol (LAN standard), such as Ethernet, FDDI or token ring, that defines the functions performed by the data link and physical layers of a communications architecture (i.e., a protocol stack). In many instances, several LANs may be interconnected by point-to-point links, microwave transceivers, satellite hook-ups, etc. to form a wide area network (“WAN”) or intranet that may span an entire country or continent.
One or more intermediate network devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a bridge may be used to provide a “bridging” function between two or more LANs. Alternatively, a switch may be utilized to provide a “switching” function for transferring information between a plurality of LANs or end stations. Bridges and switches may operate at various levels of the communication protocol stack. For example, a switch may operate at layer 2 which, in the Open Systems Interconnection (OSI) Reference Model, is called the data link layer and includes the Logical Link Control (LLC) and Media Access Control (MAC) sub-layers. Data frames at the data link layer typically include a header containing the MAC address of the entity sourcing the message, referred to as the source address, and the MAC address of the entity to whom the message is being sent, referred to as the destination address. To perform the switching function, layer 2 switches examine the MAC destination address of each data frame received on a source port. The frame is then switched onto the destination port(s) associated with that MAC destination address.
Other network devices, commonly referred to as routers, may operate at higher communication layers, such as layers 3 and 4 of the OSI Reference Model, which in Transmission Control Protocol/Internet Protocol (TCP/IP) networks corresponds to the IP and the TCP/User Datagram Protocol (TCP/UDP) layers. Data frames at the IP layer include a header which contains an IP source address and an IP destination address, while frames at the TCP/UDP layer include source and destination port numbers. Routers or layer 3 switches may re-assemble or convert received data frames from one LAN standard (e.g., Ethernet) to another (e.g., token ring). Thus, layer 3 devices are often used to interconnect dissimilar subnetworks.
Voice over IP (VoIP)
Traditionally, computer networks were used to exchange static files or data, such as text and spreadsheet files, while the Public Switched Telephone Network (PSTN) was used to exchange voice information. Computer networks, however, are increasingly being used to transport “voice” information. Voice over IP (VoIP) typically refers to a group of technologies used to transmit voice information over computer networks. Such networks include a plurality of voice agents that convert voice information from its traditional telephony form to a form that is suitable for packet transmission. In other words, the voice agent encodes, compresses and encapsulates the voice information into a plurality of data packets. Examples of voice agents include IP telephones, VoIP gateways, certain private branch exchanges (PBXs), personal computers (PCs) running communication applications, network devices providing voice gateway services, etc. A calling party uses a voice agent to initiate a VoIP call. Once the voice information has been converted into packet format, it is carried by the computer network to a second voice agent configured to serve the called party. Voice traffic, unlike static data files or records, is highly sensitive to delay and to lost packets. That is, delays in receiving data packets carrying voice information at the called party's voice agent can seriously degrade the quality of the call. Accordingly, packets carrying voice information must be delivered to the called party with high probability and in a timely manner.
Computer networks include numerous services and resources for use in forwarding network traffic. For example, different network links, such as Fast Ethernet, Asynchronous Transfer Mode (ATM) channels, SONET links, satellite links, etc., offer different speed and bandwidth capabilities. Particular intermediate devices also include specific resources or services, such as priority queues, filter settings, traffic shapers, queue selection strategies, congestion control algorithms, etc., that affect the rate at which traffic moves through the device and thus across the network. Depending on the selection or allocation of such resources or services, network traffic for different sources and sinks can be forwarded at different speeds or rates, thereby controlling the loss and/or delay experienced by the traffic.
The Resource Reservation Protocol
As set forth above, to support VoIP, packets carrying voice information must typically be delivered within narrow time constraints. Although many computer networks have the resources and services to meet the delivery requirements of VoIP, these resources and services must be allocated, preferably in advance, to the correct network traffic. The Resource reSerVation Protocol (RSVP), which is set forth in Request For Comments (RFC) 2205, is a signaling protocol that was developed so that entities (typically referred to as receivers) could reserve bandwidth within their computer networks to receive a desired data flow, such as a multimedia stream, from one or more sourcing entities.
A data flow is a sequence of messages that have the same source address and same destination address (unicast or multicast). A session is a collection of one or more data flows that have the same unicast or multicast destination address. Sessions differ from data flows in that a session may have multiple senders, whereas a data flow only originates from a single sender.
In a protocol, such as RSVP, resource reservation messages are used to establish a reservation of resources. The RSVP protocol defines two fundamental types of resource reservation messages, the RSVP Path message and the RSVP Resv message.
Pursuant to RSVP, sources send RSVP Path messages identifying themselves and indicating the bandwidth needed to receive their programming or content. These messages proceed hop-by-hop through the intermediate network devices, making those devices aware of the possibility that a reservation of resources may be required. If a receiver is interested in the programming or content offered by a particular source, it responds with a request for resources in the form of a RSVP reservation request (Resv message) which travels hop-by-hop back to the source. At each hop, the corresponding intermediate device establishes a session for the receiver and sets aside sufficient resources to provide the requested bandwidth for the desired data flow. These resources are immediately made available to the data flow. If sufficient resources are not available, the reservation is refused explicitly so that the receiver knows it cannot depend on the corresponding resources being devoted to its traffic. By using RSVP, packets carrying voice information can be accorded the resources and services they need to ensure timely delivery.
Resv messages typically include a set of options that are collectively called the reservation “style.” These options are specified in the option vector field of the style object that is included in the Resv message. One option, sharing control, concerns the treatment of reservations for different senders within the same session. This option can be specified to establish a “distinct” reservation for each upstream sender (distinct option) or make a single reservation that is “shared” among all packets of selected senders (shared option). Specifying the shared option enables the new reservation request to share resources that have already been allocated to an existing (prior) reservation. The shared option is typically used for those sessions in which multiple data sources are unlikely to transmit simultaneously.
Another reservation option, sender selection control, controls the selection of senders to the session. This option can be specified to select senders from a list of “explicit” senders (explicit option) or to select senders using a “wildcard” that implicitly selects all senders to the session (wildcard option). The sharing control in combination with the sender selection control imply (specifies) the reservation style associated with the reservation request.
For example, the shared explicit (SE) style is specified by the combination of the shared and explicit options. A SE-style reservation creates a single reservation that is shared among a specific set of senders that are sending data to a given destination. The set (explicit list) of senders are specified using filter spec objects that are included in the Resv message. Likewise, the wildcard-filter (WF) style is specified by the combination of the shared and wildcard options. A WF-style reservation creates a single reservation into which data flows from all upstream senders are mixed. As new senders appear, the reservation is extended to include these new senders.
The sharing control and sender selection control options defined by the RSVP standard provide one technique for sharing resources among RSVP sessions. Another technique that can be used to share resources is described in co-pending and commonly assigned U.S. patent application Ser. No. 09/871,108 titled System Sharing Resources Among RSVP Sessions. This technique uses a session group identifier (SGID) to enable resource sharing between distinct RSVP sessions that originate from a common source (sender) of traffic. Sessions that meet certain criteria defined by the technique are associated with a group that is designated by a SGID. Sessions within the same group share the resources that have been reserved for that group.
Specifically, a sourcing entity generates a locally unique resource identifier. The sourcing entity then uses this resource ID in the signaling to reserve resources for a first session. The sourcing entity may then decide to have these resources shared with a second session by reusing this same resource ID in the signaling to reserve resources associated with the second session. When the second session is being created, intermediate devices are configured to recognize that a reservation associated with this resource ID already exists. The intermediate devices are further configured to share the previously reserved resources between the first and second sessions, rather than reserve additional or further resources for the second session.
One problem that arises in networks that use both a shared class method, such as the SE-style or the WF-style, and the SGID method to share resources is that the rules for how the resources may be shared are not adequately defined. For example, resource sharing using the shared class method shares resources between data flows that have the same destination but different sources. On the other hand, resource sharing using the SGID method shares resources between data flows that have the same source but different destinations. A conflict may arise when both techniques are used in the same system to share resources because resources allocated using one technique may appear to be shareable to the other technique when in fact they are not.
A technique is needed that would enable resources to be shared yet, correctly allocated in all cases.